1. Field of the Invention
The present invention relates to the handling of problematic events in a data processing apparatus.
2. Description of the Prior Art
A typical data processing apparatus may have a processor core arranged to execute a sequence of instructions that are applied to data values supplied to the processor core. Typically, a memory may be provided for storing the instructions and data values required by the processor core. Further, it is often the case that one or more caches are provided for storing instructions and data values required by the processor core, so as to reduce the number of accesses required to the memory.
Some events can cause the processor core to operate incorrectly or in an unintended manner, such events being referred to herein as “problematic events”. These problematic events may, for example, arise from a problematic instruction. These problematic instructions are particular instances of instructions that, often in combination with other instructions or other micro-architectural state, cause the processor core to operate in an unintended manner. One reason for the processor core operating incorrectly or in an unintended manner is that the processor core may be found to have faults due to, for example, design errors in the hardware. These faults (also known as ‘bugs’) can lead to the processor core to respond to instructions in an unintended manner. This can lead to erroneous results being obtained. In some circumstances the problematic instructions result in sub-optimal performance being achieved by the processor core, and exceptionally the processor core will cease to operate and will require re-initialisation.
In instances where the faults can be identified before the hardware design of the processor core has been finalised, the design of the processor hardware can be adapted to rectify the faults. However, once the physical design of the processor core has been finalised, rectifying the fault is more complicated.
In Complex Instruction Set Computers (CISC) processors, so-called ‘microcode’ is provided which details a sequence of microcode operations to be performed to execute each complex instruction received by the processor. Typically, a Read Only Memory (ROM) embedded in the processor is provided which stores the sequences of microcode operations that have to be run to execute each complex instruction. When an instruction is fetched from a memory and passed to a decode stage of the processor, the ROM will be interrogated to determine the sequence of microcode operations which correspond to the complex instruction. The sequence of microcode operations is then executed. When the sequence of microcode operations is complete, the processor decodes the next instruction.
If faults are detected after the hardware design of the CISC processor has been finalised, it is possible that execution of one or more of the complex instructions could be problematic, resulting in the processor operating incorrectly or in an unintended manner. One way to overcome this problem is to use Random Access Memory (RAM) rather than ROM to store the sequences of microcode operations to be performed to execute each complex instruction. A mechanism is then provided to initialise the contents of the RAM. By this approach, it is possible to change the sequence of microcode operations to be performed to execute such a problematic complex instruction so as to provide corrective action in software for the hardware fault. In particular, when the problematic complex instruction is to be executed, the amended sequence of microcode operations will be executed, thereby automatically taking corrective action to compensate for the identified fault in the hardware.
As an alternative to the above approach, some CISC processors that use ROM to store the microcode sequences have provision for a so-called “ROM patch” to be used. In such CISC processors, a programmable mechanism is provided that enables a limited number of entries in the ROM to be overridden, thereby enabling a certain amount of amendment to the microcode sequences used to execute each complex instruction.
However, whilst the above techniques are useful in processor architectures where microcode is utilised, there are many processor architectures that do not use microcode, and hence in which the above techniques are not usable. One example is the so-call Reduced Instruction Set Computer (RISC) architecture. RISC processors implement simple instructions and do not require microcode. Rather than microcode, a hard-wired instruction decode of the simple instructions is performed, such that the instructions are directly implemented in logic. Accordingly, if there is a fault in the hardware, then it is more difficult to handle problematic instructions that can give rise to incorrect operation of the processor core or which can cause the processor core to respond in an unintended manner.
In RISC processors, it is sometimes possible to circumvent such faults through software workarounds, by in effect rewriting the relevant parts of the software to be executed on the processor core. However, this is very undesirable as it requires recompiling all of the support code, libraries, etc. Further, the worst case scenarios for every potentially problematic instruction have to be assumed, and this will often lead to a large increase in code size. This is a significant overhead.
Accordingly, it is desired to provide an improved technique for handling problematic instructions, particularly, but not exclusively, in the RISC processor environment.